Networks have traditionally been relatively difficult to administer, especially as they grow in physical size and in the number of network-attached entities. One relatively recent advance in administering networks is the directory service. A directory service organizes network entities, such as users, printers, servers and the like into a manageable hierarchy, and simplifies overall management of such entities. The advantages of a good directory service has become such an important aspect of a network operating system that network operating systems are frequently purchased solely on the strength of their directory service capabilities.
A directory service typically organizes the network entities into a hierarchical tree structure, or directory, which can be graphically presented to visually illustrate the parent/child relationships between such entities. Some vendors' directory service products allow the distribution of the directory across various servers on a network. The ability to distribute a directory across several servers can reduce network traffic and access time by allowing an administrator to place heavily used portions of a directory on the servers from which they are most frequently accessed. Of course, a distributed directory service is typically more complex to administer than a non-distributed directory service.
One directory service product, NOVELL DIRECTORY SERVICES (NDS), refers to each node in the directory tree as an object, and categorizes each object in the tree as either a container object or a leaf object. A container object can be a parent to other container objects, and to zero or more leaf objects. Container objects are typically used to provide a logical organization to the tree, while the leaf objects represent actual network elements such as servers, printers, facsimile machines, and users. The directory can be divided into distinct portions, referred to as partitions, and each partition can be located on a different network server. Multiple copies of partitions can be made, and each copy of a partition is referred to as a replica. Thus, each partition has one or more replicas.
As is apparent, the software to implement such a distributed directory service can be quite complex. The directory service is responsible for splitting and joining partitions, making and synchronizing updates to replicas, providing a coherent view of the distributed directory to an administrator, providing a mechanism for adding, modifying and removing objects, and a host of other functions. While having a directory service eases the overall administration of a network, it still requires specialized training to understand when and how to split partitions, where to place the partitions, when and how to make replicas, how to organize the objects in a tree, and other administrative issues. Moreover, it is frequently necessary to monitor the directory service to uncover potential problems before they grow to the point that service is interrupted. Administration and monitoring are typically accomplished with vendor-supplied administration software specially developed for use with that vendor's directory service. Use of these tools typically requires special training of administration personnel. Such training can be expensive, and since vendors' directory service products differ from one another, training on one such product does not necessarily help in administering another vendor's directory service. Thus, transitioning from one vendor's directory service to another typically requires costly retraining.
The difficulty in administering a directory service also arises, to a lesser extent, in the management of individual network-attached devices. Years ago, network-attached devices typically came with their own software for monitoring and maintaining the device on the network. This required familiarity with many different programs, and as the average size of networks grew, this approach became unwieldy. To ease the management of such network- attached devices, management protocols, such as the Simple Network Management Protocol (SNMP), were established which created a uniform and standard protocol for managing devices on a network. Under SNMP, each managed device implements a Management Information Base (MIB), which is a database of managed objects associated with the managed device. Each managed object in the MIB is syntactically defined in a MIB listing. The MIB listing is used by management station software running on a computer to determine what objects are implemented in a particular managed device. Through the definitions of the objects in the MIB listing, the management station can generate and communicate to the managed device with SNMP GET, SET and GET NEXT requests, to view and/or modify, as appropriate, the objects in the managed device. Thus, SNMP defines a protocol which establishes a uniform mechanism for communicating with an agent associated with a network-attached device. One of the many advantages of such a uniform mechanism is that individuals familiar with SNMP and management station software can typically, at least to some extent, manage any SNMP-enabled device, without being specially trained to manage each respective device. Another advantage of using a standardized management protocol, such as SNMP, to manage devices, is that the use of such a standard management protocol ensures that software written to interact with the managed device will run on any network which supports the SNMP protocol.
At least one attempt has been made to simplify the management of a directory service through SNMP. The CCITT has published RFC 1567 which defines a MIB for use with X.500 compliant directory services. The RFC 1567 MIB defines several objects useful for maintaining summary statistics at the Directory Service Agent (DSA) level, but provides no objects or other means for monitoring or otherwise managing a directory service at a more detailed level which includes partitions, replicas, container objects and the like, and which can provide an administrator with object-level statistics regarding network usage. Moreover, the RFC 1567 MIB does not provide any mechanism for monitoring or otherwise managing other aspects of a directory service, such as the state of the DSA, or the various types of traffic and relative amounts of traffic handled by the directory service.